Management 3.0 - Empower teams

Chapter 6 : The Basics of Self-Organization

マネジメントにとってもソフトウェア開発にとっても基本的なこと

宇宙のはじまりから、全ては自己組織化によって形成されてきた

さらにそれらが自己組織化のレベルを上げて分子になり、さらに高いレベルに至って星になったりする

生物細胞は様々な種になり、一部の生物は脳に意識を宿す

さらに社会を形成

自己組織化とは : (中央の権限や外部から課されることなく) システムに構造やパターンが現れるプロセス

動的なシステムにおける通常の振る舞い

通常の振る舞いなので、「自己組織化がベストプラクティス」 というのはばかばかしい

自己組織化には方向性があるが、それは環境によって制限される : コンテキストのない自己組織化システムは存在しない

人は歴史の中で様々な美徳を考えてきたが、自己組織化は善悪を考慮しない

そのため、人は価値あるものを守るために指揮統制 (command-and-control) の概念を採用した

指揮統制が標準で自己組織化が目新しい概念だと思う人もいるが、実際は逆

いくらかの専門家は 「自己組織化にはリーダーシップが必要であり、無政府状態 (anarchy) は別物」 だと言うが、自己組織化システムは無政府状態の複雑な異形だと考える

物理学、化学、生物学、社会学では、自己組織化にリーダーシップやマネジメント、権威は不要

無政府状態を無秩序 (chaos) と同一視して無政府状態を嫌がっているのかもしれないが、無政府状態と無秩序は異なる

システムのプロパティが、システム内の個々の部分に還元できない場合、それを創発的な (emergent) プロパティという

例 : あなたの性格は、あなたの脳の創発的なプロパティ / 流動性も水の創発的なプロパティ / 文化も人のグループの創発的なプロパティ

プロパティが創発的であるために重要な 3 つの側面

集約されたものではない (not an aggregate) : プロパティが個々のプロパティを足し合わせたものではない

下方因果関係 (downward causality) : プロパティがシステムの個々の部分に影響を与える

チームにおける創出 (emergence)

意識の 「複数の草案」 がある (Dennett)

脳内で複数の草案が一つの意識として表れるように、チームでも複数の視点を一つのチームの視点として解決できる

チームの個々の力の合計よりもチーム全体の力の方が大きくなることもある

DeMarco と Lister は 「驚異的なチーム (jelled team)」 と呼ぶ

創出的なプロパティを予測することはできない

自己組織化に似た言葉

自己組織化 (self-organized / self-managed) : 自分たちの活動を組織化する

自己選択 (self-selected) / 自己設計 (self-design) : 自己組織化に加え、自分たちを作り、維持する

チームメンバーを自分たちで選ぶ

self-directed / 自己統治 (self-governed) : 自己選択に加え、外部のマネジメントがない状態

ビーチでバレーボールをする友達同士の集まりとか、犯罪組織とか

システムの個々のエージェントは、システム全体の振る舞いについては知っていない

プロジェクトについて不完全なメンタルモデルしかもっていない → だからこそスクラムなどでは、複数人で計画することが重要

アジャイル開発はチームによるマイクロマネジメント、という意見もある

マネジャーはマネジメントをチームに移譲する必要がある

システムの良い調整者は、そのシステムのモデルを持っていなければならない

何かを制御するには、そのモデルを持っている必要がある

複雑系において、制御者が得られる情報は理解するには複雑すぎるか、適切なモデルを作るには不十分

パイロットが飛行機の制御の大部分を機械に任せるように、マネジャーもチームの制御をチームに任せる

それこそが複雑系をマネージする方法

分散制御

自分の中の心臓の鼓動の速さや消化システム、免疫機構などは、自分では制御できない (それらは自分のサブシステム)

中央での単一の制御は、システムから強固さも弾力も失わせる

複雑系において、分散制御は生き残るために重要

エンパワメントという言葉は、「通常は部下から力を奪っている」 というような意味を与えかねないためよくない、という主張もある → 「部下」 と呼ぶのをやめて 「同僚」 や 「パートナー」 と呼ぶ、というような

パートナーと呼ぶのはよい考えだが、それでもエンパワメントはマネジャーの責任

どういう権限を誰に与えるかはマネジャーだけが決められる

エンパワメントはビジネスオーナーからはじまる

が、そのとき必ずしも組織が階層構造であるとは限らない

例えば、家の鍵を渡して毎週の掃除を頼む、みたいなのもエンパワメント

聡明な制御は、制御していなかったり自由なように見える

影響を与えていないように見せて影響を与える

聡明でない制御は、外部からの統治として表れる

マネジャーとして自分の目標を伝えて、それに向かって動いてもらうべき

エンパワメントは動機づけとして解釈されることもあるが、それは正しくない

実際は、マネジメント可能性を高める

ネットワーク上の 1 ノード (個人) が持っている情報より、ネットワーク上の情報の方が多い

喜ばせるためにするのではなく、より良い決断をするためにエンパワメントする

構築された系 (飛行機や橋など) と複雑系 (企業やニワトリなど) に対するマネージの違い

複雑系は日々変化する

家や道路を構築することはできるが、都市を構築することはできない (都市を成長させることはできる)

同様に、コードや設計ドキュメント、ビルドされた成果物を構築することはできるが、ソフトウェアシステムを構築することはできない (それは成長させるもの)

チームビルディングというのも適切でなく、正しくはチームを成長させる

建築のメタファーではなく、農業のメタファーが適切

生きているシステムは最初は急速に成長し、その後成熟のレベルに達する

成熟したシステムやチームに対してはそれほど注意する必要はない

問題のほとんどは自身で修正できる

庭園が管理されていないと、成長し続けて、意図したものとは異なる方向に進みうる

ソフトウェアシステムとチームも同様

成長している多くのシステムには、特定の平均寿命があり、それらは衰退して死ぬ傾向がある

開発者もマネジャーも、システムに対する庭師という点では同じ

Chapter 7 : How to Empower Teams

知識には力がある。 知識労働者は知識によって力を与えられている

マネジャーは採用の権限を持っているが、最も重要なのは知識労働者

マネジャーはスポーツチームの監督のよう

やるべきでないこと

偉そうに指示して動機づけの負債を作らないこと

そうではなく、依頼すること

魔法使いのように振る舞う

著者の経験 : プロジェクトマネジャーが休暇に入る際に代理でマネジメントを行った

プロジェクトマネジャーが帰ってきてから聞いたところ、メンバーはプロジェクトマネジャーより著者のマネジメントを好んだ

プロジェクトマネジャーは政治家のように細かくコミュニケーションすることを好み、詳細を管理した。 著者は問題を解決することを好み、把握したいこととしたくないことを伝え、魔法使いのよう

多くの 「ピープルマネジャー」 は人をマネージすることを知らない

エンパワメントと委任 (委譲) は異なる

委任は、誰かに責任を引き継ぐこと

エンパワメントは単なる委任以上のこと。 リスクを取ること、人の成長、文化変容を含む

リーダーはその存在を認識されないぐらいがもっともよい。 リーダーの目的が達成されたときに、メンバーが 「自分たちがこれをやった」 と言うようなイメージ

言うは易しだが、実際にやるには組織の変容が必要 (しかもすぐには結果がでない)

エンパワメントを嫌がるマネジャーもいる (自分が居なくてもいいような状況になったら解雇されると思うなど)

が、実際はチームの力が増すので、そのマネジャーとしての地位も上がる

エンパワメントされることもまた技能であり、簡単なものから始めるべき

エンパワメントのレベル

低レベル : コーディングガイドラインの作成や、社内ワークショップの準備、クリスマスツリーの飾りつけなど

簡単に始められるが、組織が一定のレベル以上にあるならこのエンパワメントは目標として低すぎるので、手を出すのは避けた方が良い場合もある

中レベル : 採用面接や社内教育、労働時間の自由やツール選択など

組織によっては難しいエンパワメントではあるが、全ての組織はこの水準のエンパワメントを達成すべき

高レベル : 自分たちの給与を一緒に決める組織、望んだプロジェクトでのみ働けるような組織、職種の区別がなく、全員が 「仲間」 と呼ばれる組織、など

組織によっては達成不可能かもしれない。 既存の組織を変えるより、新しい会社を作る方が達成できるかもしれない

適切な権限レベルを選択する

エンパワメントは権限を渡すか渡さないかの 2 択だと思われがちだが、段階がある

7 段階

Level 1. Tell : マネジャーが決めて、マネジャーが伝える (これはエンパワメントされていない状態)

Level 2. Sell : マネジャーが決めるが、その考えをメンバーに売り込むことで約束を得ようとする

Level 3. Consult : 決定する前に、マネジャーがメンバーからインプットを受けて検討する。 決定はマネジャーが行う

Level 4. Agree : メンバーに決定に参加してもらい、グループとして合意する。 マネジャーの声はメンバーと同等

Level 5. Advise : マネジャーの意見をメンバーに伝えて影響を与えるが、究極的には決定をメンバーに任せる

Level 6. Inquire : 後で納得させてもらえればうれしいということで、チームに決めてもらう

Level 7. Delegate : 完全にチームに任せる

Level 1、2、4、5 の状態は Situational Leadership Theory で議論される 4 つのリーダーシップスタイル

この理論を拡張したのがこの 7 段階

誰に権限を渡すか？ (チーム or 個人)

物によって異なる。 例えばプロダクトバックログアイテムの追加の最終決定権は 1 人だけにする (プロダクトオーナーとしてのツールなので)

チーム全体には Level 3 でエンパワメントし、1 人だけ Level 4 にする、とか

誰か一人に仕事をお願いするが、その誰かはチームで決めるよう頼む、とか

委譲のチェックリスト (いずれも Yes であるべきで、そうでないならオープンに議論すべき)

1. この作業を委任することのリスク要因は適切に対処されているか？

2. 人々は適切なエンパワーメントの技能と規律を持っているか？

3. 適切な権限レベルを検討して選択したか？

4. 個人またはチームのどちらに委任するか (?) を検討しましたか？

5. 独立した作業を委任しているか？

6. 委任先の人は、その仕事をするスキルを持っているか？

7. 委任先の人は、作業成果物の適切な形式を持っているか？

8. 委任先の人は、成功するために必要なツールを持っているか？

9. 委任先の人は、結果がどうあるべきかを知っているか？

10. 作業の境界条件を設定したか？ (予算、時間、リソース、品質など)

11. 仕事の期限を人々は知っているか

12. 人々は進歩がどのように見えるか知っているか？

13. 人々は、進捗状況を報告する頻度を知っているか？

14. 助けが必要になったときにコーチやメンターをできる人はいるか (マネジャー自身でも他の人でも)

委譲しようとしてマイクロマネジメントしてしまうのはよくない

「相手はまだこれをする準備ができていない」 という考えは委譲の障害

問題は、それが大体は正しいこと。 なぜならその能力があるなら彼らは既にそうしているはずだから

ただし、そうした状況で 「自分でやる」 というのは最善策ではない

委譲を投資として考える必要がある

投資の回収には時間がかかる。 忍耐が必要

うまくいかないときに委譲をすぐにやめるのではなく、何が悪かったかを考えること

経営陣 (自分の上司) から、状況を制御下に戻すように圧力がかかることがある

そのとき、仕事を自分でするようにしたいという欲望と戦い、委任の方法を管理下に置くようにする

委任のチェックリストを上司に見せるなどして、対応する

上司は結果を気にしているのであって、どのように結果を出すかは気にしていない。 方法を決めるのはあなたである

エンパワメントを人々の内的な欲望に結び付ける

承認なしで行動することを怖がったり、チームメンバー同士で責任を持ち合うことで上司が複数いるように感じる人もいるので、その対策

ドキュメント管理に課題を持っている人にドキュメント管理を任せる、といったこと

エンパワメントを阻害する第三者として環境 (システム管理者や人事なども含む) がある

セキュリティポリシーで運用サーバーへのアクセスを禁止する、など

この時はマネジャーが介入して状況を修正する

その状況でできる最善のことは、一緒に座って、コスト、メリット、リスク、および機会の客観的なリストを作成すること

コスト、メリット、リスク、および機会のバランスは通常、途中で終わる (何らかの形で妥協する必要)

妥協は何もしないよりはまし

信頼

マネジャーとチームの信頼は 4 種類

マネジャーからチームへの信頼

チームからマネジャーへの信頼

チームメンバー同士の信頼

マネジャーがマネジャー自身を信頼

チームへの信頼

仕事を委任したら、その仕事をするのはチームである

あなたに助けを求めてきたら、チーム自身で解決策を見つける方法を見つけること

事前に決定について相談してほしい場合はそれを明確に伝えること。 そうしていない場合に事前の相談がないからといって批判しないこと

チームからの信頼の獲得

信頼してもらうには、信頼を獲得する必要がある。 約束を守ることで信頼を積み上げられる。 壊れるのは簡単

チーム内での信頼

できたばかりのチームとか、地理的に離れているとかの場合は支援が必要かも

通信帯域幅と品質の向上とか。 新しいチームメンバーがコミュニケーションとコミットメントに全面的に参加できているか見守るとか

自分自身を信頼

他人を助けるにはまず自分の身の安全。 他人を愛するにはまず自分を愛する

同様に、他人を信頼するにはまず自分を信頼

自分の考えを変えるときには、自分が納得してから

尊重

従業員への不敬は最も一般的な組織病

重要性は委譲と関連付けられやすい。 委譲する人は委譲される人より重要だとみなされやすい

それが組織に伝搬すると、尊重が生まれない

マネジャーは組織内の不敬を排するためにできる限りのことをすべき

フィードバックを受けよ

私がやめるべきことは何か？

何から始めたらよいか？

私が続けなければならないことは何か？

尊重の目標は、生産性、創造性、革新性を高めること

幸福は主目的ではなく、歓迎すべき副作用

優れたマネージャーとして、あなたは人々があなたについてどう思っているか知る必要がある

他にできることは、チームメンバーの仕事を本当に理解し、貴重なフィードバックを提供すること

ソフトウェア開発者や他の IT 専門家がマネジャーに求めるのは、自分の仕事を理解し、それが何を達成しようとしているのかを理解することである

まとめ

最高のマネジャーはファンタジーの物語の魔法使いのよう。 主人公が困難に打ち勝つために助ける (彼らのために仕事をするわけではない)

エンパワメントされたチームはよりよいパフォーマンスを発揮する

マネジャーは仕事を委譲するにあたって、3 つの成熟レベルと 7 つの権限レベルを参照できる

エンパワメントは投資であり、利益を得られるまで時間がかかる。 忍耐が必要

信頼と尊重